Generally described, a typical computer system architecture provides two primary modes for execution of software application instructions. The modes of execution are enforced by a processor when executing instructions sent by a software application. Generally described, the two modes correspond to a level of trust placed on the application by an operating system to ensure system stability and reliability. The first mode, typically referred to as the user mode, provides the lowest level of protection and corresponds to all external user modules and some operating system models functioning as utilities. The operating system classifies modules as user mode modules in an attempt to allow the operating system to continue to function even if a user mode module incurs an error. The second mode, referred to as the kernel mode, provides the highest level of protection and typically corresponds to core operating system application modules and driver modules that interact with the user mode modules. Unlike user mode modules, errors in a kernel mode module will typically result in the complete crash of the operating system.
In certain situations, errors can occur within user mode modules that prevent the application from running as desired. Additionally, in some instances, errors within kernel mode modules can prevent the operating system from running as desired. To improve application and operating system stability and reliability, it is often desirable to collect and process information corresponding to the user mode modules and/or kernel mode modules being implemented by a particular application prior to the occurrence of an error. Because user mode module errors do not always result in the crashing of the operating system, typical operating system utilities can collect and provide information regarding the state of the user mode module prior to the occurrence of the error. However, user mode module error information is limited in nature and cannot always accurately describe the nature of the error absent additional kernel mode module information. Accordingly, the ability to obtain as much information about the user mode modules and the kernel mode modules provides for improved error debugging.
Current kernel mode module information gathering techniques are either intrusive or destructive in nature. In one approach, a computing device may include a second processor that collects and provides kernel mode module data as the first processor executes the kernel mode module instructions. However, the utilization of a second processor for error checking is not practical for many users because it requires a redundant processor for error checking. Accordingly, the dedicated processor approach is not a feasible approach for continuously collecting error information from a large group of users.
Many operating systems have provide an operating system utility, referred to as a data dump, that captures information corresponding to the threads being executed just before the operating system crashes. Accordingly, in another approach to collecting kernel mode information, the user mode module can force the operating system to crash and invoke the data dump functionality. However, this approach is largely destructive by requiring the operating system to crash and requiring a user to reboot the operating system. Further, because the utility is limited to capturing information corresponding to current threads and cannot be directed to capture specific kernel mode data corresponding to the user mode module crash.
Thus, there is a need for a system and method for collecting kernel mode module data for application errors without requiring intrusive or destructive collection mechanisms.